From: Mary Boetcher, mary_boetcher@quickmail.apple.com
Reply-To: ODF Interest, ODF-Interest@CILabs.ORG
To: OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
Reply to: RE>>Linking & ODF Draw
>>It appears that the indices are assigned when
>>the part is internalized from storage, via "PostInternalizeShape",
>>ditto for the selection. So, if I create a new document, draw some
>>shapes, save the doc, and reopen it, the shapes will be numbered
>>1..n. Then I paste some more shapes, now my doc's shape list is
>>numbered 1..n, 1..m. Now I select some shapes (including some that I
>>just pasted in). Let's say I have 8 shapes altogether, numbered 1..5,
>>1..3, and I select the first, third and last shape. When I copy, the
>>selection is externalized with the shape indices of 1, 3 & 3.
Actually the selection is externalized with the shape indices of 1, 2 & 3, because the index is reset in CDrawContent::ExternalizeShapeList. However, I see a potential problem when this selection is internalized. If the part's existing shapes are numbered 1..n, then CDrawPart::FindShapeWithIndex may return the wrong shape. I will investigate this further.
>>what really
>>confuses me is that ODF Draw uses the same content base class for
>>both its part storage as well as its selection, but in my case (and
>>maybe others as well) that is not a workable model. It also makes the
>>code harder to understand since when one is in some overriddem member
>>function, it isn't obvious which shape list is being used.
The reason the same content base class is used for both part and selection storage is simply that the content is kept in the same form (a shape list) and many operations are the same (AddShape, IsEmpty). Other samples, such as ODFTable, use separate subclasses of FW_CContent for the part content and selection content.
